1. Technical Field of the Invention
The present invention relates to three dimensional (3D) application development for mobile devices (such as G4M-type devices) using the OpenGL|ES graphic standard and, in particular, to a translator which functions to allow running of an OpenGL application on top of an OpenGL|ES implementation.
2. Description of Related Art
The 3D graphic standard OpenGL is commonly used for graphics rendering in personal computer (PC) environments. The graphic standard OpenGL|ES is a lite version of the OpenGL standard which targets mobile devices such as mobile phones and other handsets. Although the OpenGL|ES standard is established, a problem exists in that the OpenGL|ES standard is so new that there are very few 3D applications based on that standard which are available in the market. There do exist, however, a sizable number of legacy applications which were written for the personal computer in OpenGL. Until more suitable OpenGL|ES standard-based applications appear on the market, consumers would like an opportunity to run the many OpenGL standard-based applications on their mobile devices. The differences between OpenGL and OpenGL|ES, however, preclude this from happening to any degree of consumer satisfaction, especially with respect to graphically intensive applications such as 3D games.
Among all the primary OpenGL APIs (Application Programming Interfaces, sometimes referred as commands) only about 10% are retained in OpenGL|ES with no changes. About 50% of the OpenGL APIs are retained in OpenGL|ES with minor changes such as allowing fewer, different or new parameters. The rest of the primary OpenGL APIs are not supported in OpenGL|ES at all. With respect to an OpenGL based application and an OpenGL|ES rendering engine implementation, for the APIs of the first category, which are fully supported by OpenGL|ES, the related commands sent by the OpenGL application can be sent straight forward to the OpenGL|ES graphic rendering implementation. However, with respect to the restricted support OpenGL commands, for example where only restricted parameters are supported, and the not supported at all OpenGL commands, some translation work is necessary to be able to run the application properly on the OpenGL|ES implementation.
Dylogic provides a translator program called “DOGLESS” which translates OpenGL calls into OpenGL|ES and forwards them to the underlying OpenGL|ES implementation DLL. See, http://sourceforge.net/projects/dogless. In order to run an OpenGL application over an OpenGL|ES implementation, Dylogic's translator intercepts in runtime OpenGL commands not supported in OpenGL|ES, and tries to translate these commands by using supported commands. This functionality is depicted in the flow diagram of FIG. 1. With this solution, some OpenGL applications and games, including graphically intensive games like Quake 2, can run properly over the OpenGL|ES implementation.
The Dylogic translator of FIG. 1, however, is a proof-of-concept product and translates only a very few number of the OpenGL APIs. Furthermore some of these translations are game dependent as will be discussed in more detail below. For example, the Dylogic translator is known to work somewhat well with the game Quake 2, but not with other games.
To submit the vertex data (coordinates, color, normal . . . ) of a polygon to render, OpenGL supports two ways: a) the “immediate mode” where the data are sent vertex by vertex between two GL commands: the glBegin/glEnd paradigm (an example is shown FIG. 5); or b) using vertex array for each data type. In OpenGL|ES, however, only the vertex array method is supported. Vertex arrays are more efficient since all the primitive data is sent in a single command. The Dylogic translator tool focuses almost exclusively on the translation of the glBegin/glEnd paradigm. This is shown in FIG. 2.
The Dylogic translator solution translates the glBegin/glEnd paradigm to vertex arrays as follows: in a glBegin command, all vertex arrays are activated by using command glEnableClientState (which enables all arrays for color, normal vertex, texture coordinate). This effectuates a transform of complicated primitives into triangles. Then the data for vertex arrays are prepared by assembling the data specified in commands glVertex, glColor, glTexCoord and glNormal. Next, with the glEnd command, the vertex arrays are passed to implementation and the object is rendered using API glDrawArray.
What can easily be observed from a review of the Dylogic translator solution is that the translation work is much too simplistic for a number of reasons. First, given the needs of the application (color, normal, texture coordinate), the Dylogic solution enables all the client vertex data array pointers for vertex coordinates, color, normal and texture coordinates as well as passes the related arrays to the rendering engine. This means that useless commands and data are used in the solution which might lead to a waste of resources and a dramatic loss of performance. Second, in the Dylogic solution no array states are recorded and restored in the glEnd command. This could present memory problems. Third, the Dylogic solution fails to take into consideration multiple textures.
It is recognized by those skilled in the art that the OpenGL specification defines optional APIs, also called “extensions”, which are proposed by graphic companies and sometimes included as core additions in the specification. Most of the recent popular games use part of these extensions. Unfortunately, the Dylogic translator solution does not treat these extensions at all.
In sum, the Dylogic translator solution is an incomplete solution, at best, and is not optimized to be able to run substantially all, if not all, OpenGL applications over a compliant OpenGL|ES implementation. A need accordingly exists in the art for such a translator solution.